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[57] ABSTRACT 

A method and system for providing seamless interoperabil- 
ity and integration of a plurality of devices in a network. 
When a new device is coupled to a home audio video 
network, the device is queried to obtain a description of first 
level functions supported by the device. A first level control 
module which implements the first level functions is gen- 
erated for the device based upon the description. If the new 
device contains software for implementing second level 
functions, the software is retrieved from the device and a 
second level control module which implements the second 
level functions is generated using the software. The device 
is subsequently accessed via the control module in order to 
access the first level functions or the second level functions 
and provide seamless interoperability and integration of the 
device with the plurality of devices in the network. 
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HOME AUDIO/VIDEO NETWORK WITH Another problem is the lack of functional support for 

TWO LEVEL DEVICE CONTROL differing devices within an audiovisual system. For example, 

n nv ttju im/rwrrnw even ^ough a television may support advanced sound 

FIELD OF THE INVENTION formats (e g ^ swoun6 sound) stereQ) cta)> if an oldcr kss 

The field of the present invention pertains to audio-video s capable tuner does not support such functionality, the ben- 
systems. More particularly, the present invention pertains to efits of the advanced sound formats can be lost, 
a networking of a number of electronic devices to form an Another problem is the proliferation of controls for the 
audio video system. new and differing devices within the home audiovisual 
BACKGROUND OF THE INVENTION system. For example, similar devices from different manu- 
, . . , • i , 10 facturers can each have different control buttons and control 
Atypical home audiovisual equipment set up includes a switch for a similar Usks ( setti 

number of components. For example, a radio receiver, a CD ^ ck)ck Qn a y programming a VCR record a later 

player, a pair of speakers, a television, a VCR, a tape deck and ^ In addition> eacn new device coupled l0 

and al.ke. Each of these components are connected to each ^ audiovisual tem oflen leads to ^ dedicated 

other via a set of wires. One component isusuaUy the central , s remote control ^ for ^ user tQ k ^ of and , ear[J (Q 

component of the home audiovisual system. This is usually 

the radio receiver, or the tuner. The tuner has a number of „„ .,* , . , . r . , 

specific inputs for coupling the other components. The tuner ™^ ™^ C ' ° f nc , tworkln e and . ml f AW 

has a corresponding number of control buttons or control i^' * ^ 139 5 J ser ( la , 1 communication bus and the 

switches which provide a limited degree of controllability 20 wide spread adoption of digUal systems offers prospects for 

and interoperability for the components. The control buttons correcting these problems, there is still no coherent, open 

and control switches are usually located on the front of the extensible architecture which can provide for intelligent, self 

tuner. In many cases, some, or all, of these buttons and configurmg easily extensible devices or AV systems^ For 

switches are duplicated on a hand held remote control unit. « a n m P le >, ? hl ^ vario f us solutions involving the use of IEEE 

A user controls the home audiovisual system by manipulat- 25 b ff A \ system, none prov.de for the 

ing the buttons and switches on the front of the tuner, or extensibility of the AV system over Us life Ume as new 
alternatively, manipulating buttons on the hand held remote 
control unit. 

This conventional home audiovisual system paradigm has 
become quite popular. As consumer electronic devices 

become more capable and more complex, the demand for the SUMMARY OF THE INVENTION 
latest and most capable devices has increased. As new 

devices emerge and become popular, the devices are pur- Accordingly, what required is a new architecture for a 
chased by consumers and "plugged" into their home audio- home audiovisual system which corrects the interoperability 
visual systems. Generally, the latest and most sophisticated 35 and functionality problems of the conventional system, 
of these devices are quite expensive (e.g., digital audio tape What is required is a new architecture for an open, rater- 
recorders, DVD players, digital camcorders, and alike). As operating, audiovisual system for devices within a home 
a consumer purchases new devices, most often, the new network. What is required is an architecture which allows 
device is simply plugged into the system alongside the devices from any manufacturer to function seamlessly with 
pre-existing, older devices (e.g., cassette tape deck, CD 40 a home audiovisual system. What is required is an architec- 
player, and the like). The new device is plugged into an open hire which is extensible, and can be readily modified and 
input on the back of the tuner, or some other device couple advanced as market requirements and technology change, 
to the tuner. The consumer (e.g., the user) controls the new The present invention provides a home audio visual (AV) 
device via the control buttons on the tuner, via the control network which defines an open architecture for inter- 
buttons and control switches on the front of the new device 45 operating CE (consumer electronic) devices in a home 
itself, or via an entirely new, separate, respective remote network. The interoperability aspects of the present inven- 
control unit for the new device. tion define an architectural model that allows CE devices 
As the number of new consumer electronics devices for from any manufacturer to inter-operate and function se am- 
ine home audiovisual system have grown and as the sophis- lessly within the user's home AV system. The system of the 
tication and capabilities of these devices have increased, a so present invention includes a combination of a base set of 
number of problems with the conventional paradigm have generic device controls with a method to extend a base 
emerged. One such problem is incompatibility between control protocol as new features and new CE devices are 
devices in the home audiovisual system. Consumer elec- deployed within the home AV network. In so doing, the 
tronic devices from one manufacturer often couple to an architecture of the present invention is extensible, and can be 
audiovisual system in a different manner than similar 55 readily modified and advanced as market requirements and 
devices from another manufacturer. For example, a tuner technology change. 

made by one manufacturer may not properly couple with a To implement the above features, the present invention 
television made by another manufacturer. includes an architecture that allows the newly coupled 
In addition, were one device is much newer than another device to be queried. Using the results of the query, a 
device additional incompatibilities may exist. For example, 60 software based abstraction of that device is generated and 
a new device might incorporate hardware (e.g., specific made available to other elements in the network. The 
inputs and outputs) which enables more sophisticated software abstraction is referred to as a device control mod- 
remote control functions. This hardware may be unusable ule. The device control module provides a predefined, 
with older devices within the system. Or, for example, older standardized, set of interoperability, functionality, and con- 
tuners may lack suitable inputs for some newer devices (e.g., 65 trol interfaces for the device. The CE device is coupled to 
mini-disc players, VCRs, etc.), or may lack enough inputs and communicates with the home AV network via a device 
for all devices of the system. control module. Each CE device in the home AV system has 
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a corresponding device control module (DCM). The DCM FIG. 5 shows an exemplary HAVI network having mul- 

of the present invention also provides an application pro- tiple FAVs. 

gramming interface (API) to allow other applications to piQ. 6 shows a diagram of a set top box in accordance 

access and manipulate any newly coupled CE device. w i t h one embodiment of the present invention. 

Through the DCMs of the present invention, over the life s RG ? shows a logical block diagram of one embodiment 

time of the AV system, as new devices are added whose of the HAVI architecture of the present invention, 

capabilities and features are unknown, or only partially CTr , Q u , ji j* * xjwn 

* . , . t_ . • jji-l FIG- o shows a layered logic diagram of one HAVI 

known to other devices, a mechanism is provided which n , , ^ ■ - tU iUa 

„ . . . • j . * . architecture in accordance with the present invention, 
guarantees that all devices can be communicated with and 

controlled at some basic minimal level, and then where io FIG 9 shows a diagram of local and remote messaging m 

possible, as more information is obtained about the device, the HAVI architecture of one embodiment. 

a better abstraction of the new device is created. FIG. 10 shows a diagram of a message being sent via 1394 

Specifically, in one embodiment of the present invention, ™ the HAVI architecture of one embodiment, 

when a new device is coupled to a home AV system, a FIG. 11 shows a diagram of an application invoking 
default (referred to as level one) DCM is automatically 15 another application in one embodiment of the HAVI archi- 

generated for the new device. A device manager (e.g., a tecture. 

software based control object) executing on one of the FIG. 12A shows a first exemplary UI display (e.g., on a 

devices in the AV system automatically determines the basic television screen) for a device (e.g., the camcorder), 

characteristics of the device, categorize the device into a p IG shows a second exemplary UI display (e.g., on 

class (e.g., which share common features), and initializes a a telcvision scrccn ) for a device(e.g., the camcorder), 

generic, or default, DCM for the device (which corresponds ^ flow ^ ^ for 

to that class of device). In so doing, the level one DCM of , . . ..... , . , - * 1W % 

. . ' . „ , j . . seamless interoperabihty and integration of a plurality of 

the present invention ensures that no matter what device is , . . tt AT7T t , u . tU cnn r. *. 

j tl _ . ti . u • i i j * devices in a HAVI network by using the SDD information 

added, the system is able to create a basic level device , . , , . . / , . P 

' , 3 . , . . .m . < . - £• ■!".* stored in each device m accordance with one embodiment of 
controller (e.g., level one) and make the device s facilities LD ^ e resent invention 
available to other parts of the system and to the user. 

~ . t , . ... ,. t . , . £ t • . c . . FIG. 14 shows a flow chart of a process for providing a 

Dunne this initialization phase, if the device is found to , . , . . , r , j & , 

i .° J , r c ' * , ... basic command functionality and an expanded command 

contain pseudo code, or a reference to pseudo code, which . . , ^ . J - c r . . TT ., 7T 

, r t . , . . t . . , r^^/f functionality between a plurality or devices in a HAVI 

implements a more capable or a more sophisticated DCM . . J , ,K . j- , ftL 
£ ji j ■ ii. j ■ * • *l j j 30 network m accordance with one embodiment or the present 

for the device, the device manager retrieves the pseudo code invention 
and initializes a DCM based upon the pseudo code. This is 

referred to as a level 2 DCM. In this case, since such pseudo FIG - 15 shows a flow chart of a process for ensuring 

code is typically provided by the device's manufacturer and future upgradability and expandability of devices in HAVI 

is therefore more intimately familiar with the hardware of network in accordance with one embodiment of the present 

the device, is able to offer a better software abstraction of the invention. 

device's capabilities. Depending upon the devices included FIG. 16 shows a flow chart of a process for providing 

in the AV system, either, or both, of the DCMs are initialized seamless interoperability and integration of legacy devices 

and instantiated. with the HAVI compliant devices in a HAVI network in 
By making both the level 1, and level 2 DCMs of the 4Q accordance with one embodiment of the present invention, 

present invention available, the system of the present inven- FIG, 17A shows a flow chart of a process for controlling 

tion ensures that any new devices added to the home devices within a home audio/video network using an appli- 

network are seamlessly and easily made available to cation program from an external service provider accor- 

applications, system software, and the consumer. In so dance with one embodiment of the present invention, 
doing, the present invention provides an extremely flexible 45 piG. 17B shows a diagram of a HAVI network with the 

mechanism that ensures that not only will new devices service provider in accordance with the process of FIG. 17 A. 
become part of the AV system, but that they will be accessed 

in different ways depending on capabilities of the other DETAILED DESCRIPTION OF THE 

devices in the AV system. INVENTION 

BRIEF DESCRIPTION OF THE DRAWINGS 50 Reference will now be made in detail to the embodiments 

„ . . . .„ ( . j k P i of the invention, examples of which are illustrated in the 

The present invention is illustrated by way of example . ' . r ... .,, , 

, *V n- • iL e fiL accompanying drawings. While the invention will be 

and not bv way of limitation, in the figures or the accom- , , . ° . . ° . , c , . ,. 4 

anu m» vjj y ul iiu^t u, B described in conjunction with the preferred embodiments, it 

panying drawings and in which like reference numerals refer ^ be ^ th are Med t0 Hmit the 

to similar elements and in which: inventkm tQ ^ embodiments 0n the cont the inven _ 

FIG. 1A shows a home AV network id accordance with ^ ^ intended tQ CQVer alternativeSj mod i fica tions and 

one embodiment of the present invention. equivalents, which may be included within the spirit and 

FIG. IB illustrates a logical bus configuration of the scope of the i nverj tion as defined by the appended claims. 

HAVI network of FIG. 1A. Furthermore, in the following detailed description of the 

FIG. 2, shows an exemplary peer to peer, two IAV 60 prcS ent invention, numerous specific details are set forth in 

(intermediate audio video) node network in accordance with order to provide a thorough understanding of the present 

one embodiment of the present invention. invention. However, it will be obvious to one of ordinary 

FIG. 3 shows a single FAV (full audio video) cluster HAVI skill in the art that the present invention may be practiced 

network in accordance with one embodiment of the present without these specific details. In other instances, well known 
invention. 65 methods, procedures, components, and circuits have not 

FIG. 4 shows an FAV cluster integrated with an IAV peer been described in detail as not to unnecessarily obscure 

to peer HAVI network. aspects of the present invention. 



11/20/2003, EAST Version: 1.4.1 



6,032,202 

5 6 

The present invention provides a home AV network which devices to be integrated into the network and provide their 

defines an open architecture for inter-operating CE devices services in a seamless manner. The home AV network is the 

in a home network. The interoperability aspects of the term used to describe the physical network and its topology, 

present invention define an architectural model that allows [t should be noted that the home AV interoperability 

CE devices from any manufacturer to inter-operate and s (HAVI) architecture of the present invention is an open, 

function seamlessly within the user's home AV system. The platform-independent, architecturally-neutral network that 

system of the present invention includes a combination of a allows consumer electronics manufacturers and producers to 

base set of generic device controls with an method to extend provide inter-operable appliances. It can be implemented on 

a base control protocol as new features and new CE devices different hardware/software platforms and does not include 

are deployed within the home AV network. In so doing, the 10 features that are unique to any one platform. The interop- 

architecture of the present invention is extensible, and can be erability interfaces of the HAVI architecture are extensible 

readily modified and advanced as market requirements and and can be added to, modified and advanced as market 

technology change. The present invention and its benefits requirements and technology change. They provide the 

are further described below. infrastructure to control the routing and processing of iso- 

15 chronous and time-sensitive data (e.g., such as audio and 

NOTATION AND NOMENCLATURE video content). 

Some portions of the detailed descriptions which follow Specifically, the HAVI architecture provides: an execution 
are presented in terms of procedures, steps, logic blocks, environment supporting the visual representation and con- 
processing, and other symbolic representations of operations trol of appliances; application and system services; and 
on data bits within a computer memory (see FIG. 2). These 20 communication mechanisms for extending the environment 
descriptions and representations are the means used by those dynamically through plug and play or otherwise, 
skilled in the data processing arts to most effectively convey It should be noted that the HAVI architecture supports 
the substance of their work to others skilled in the art. A legacy appliances (e.g., appliances that already exist and are 
procedure, computer executed step, logic block, process, available to users). This is important since the transition to 
etc., is here, and generally, conceived to be a self-consistent 25 more intelligent networked appliances is going to be slow, 
sequence of steps or instructions leading to a desired result. Most manufacturers will not suddenly begin producing only 
The steps are those requiring physical manipulations of "intelligent" appliances and most consumers will not 
physical quantities. Usually, though not necessarily, these quickly begin replacing all of their existing appliances, 
quantities take the form of electrical or magnetic signals ^ i n accordance with the present invention, there are two 
capable of being stored, transferred, combined, compared, classes of legacy appliances. A first class includes "one- 
and otherwise manipulated in a computer system. It has way" or unacknowledged control appliances. A second class 
proven convenient at times, principally for reasons of com- includes controllable "two-way" appliances. Examples of 
mon usage, to refer to these signals as bits, values, elements, one-way appliances are audio/video components controlled 
symbols, characters, terms, numbers, or the like. 35 by infrared commands of a hand held remote. Two-way 

It should be borne in mind, however, that all of these and appliances provide confirmation of command execution, 

similar terms are to be associated with the appropriate status and error reporting. Examples of two-way appliances 

physical quantities and are merely convenient labels applied include the recent introduction of well known IEEE 1394 

to these quantities. Unless specifically stated otherwise as enabled digital cameras. 

apparent from the following discussions, it is appreciated 4Q It should be noted that the home AV network (hereafter 
that throughout the present invention, discussions utilizing HAVI network) of the present invention provides support to 
terms such as "processing" or "computing" or "translating" accommodate future appliances and protocols through a 
or "instantiating" or "determining" or "displaying" or "rec- write-once, run-everywhere common language. In accor- 
ognizing" or the like, refer to the action and processes of a dance with the present invention, each appliance includes 
computer system, or similar electronic computing device, 45 within it self -describing information concerning the user 
that manipulates and transforms data represented as physical interface and the device control that can be used by an 
(electronic) quantities within the computer system's regis- external controller. This information is specified as pra- 
ters and memories into other data similarly represented as grams in the common language. 

physical quantities within the computer system memories or described below, the underlying structure for such a 

registers or other such information storage, transmission or 50 network consists of set of interconnected clusters of appli- 

display devices. ances. Typically, there will be several clusters in the home, 

with one per floor, or per room. Each cluster will work as a 
ARCHITECTURE OVERVIEW gct of interconnected devices to provide a set of services to 
The Architecture of the present invention enables the users. Often, one device will act as a controller for a set of 
creation of a Home AV system which provides for seamless 55 other devices. However, the architecture is sufficiently flex- 
support of new devices and problem free interoperability of ible to also allow a home to consist of a single cluster with 
devices in a home AV network. The most basic components no master controller. 

of a system in accordance with the present invention are: a • For example, in one embodiment of the present invention, 

home AV interoperability architecture, a series of home AV an intelligent television in the family room of a user's home 

interoperability interfaces, and a home AV network. The 60 might function as the controller for a number of intercon- 

home AV interoperability architecture is a broad, over arch- nected appliances. Each of the controlled appliances would 

ing term encompassing the physical network and the con- have self describing data and possibly some associated 

trolling programming interfaces. Interoperability interfaces control code. When these appliances are first connected, the 

is a term used to describe the interactions and interfaces of controller obtains the user interface and the control program 

the components of the AV architecture. In addition to pro- 65 for the appliance. An icon representing the appliance may 

viding a common command set, the interoperability inter- then appear on the television screen, and manipulating the 

faces provide a software architecture which allows new icon may cause elements of the control program to actuate 
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the represented appliance or appliances in prescribed ways. 
The exception to this model are legacy devices which will 
have neither self describing data or control code. For addi- 
tion descriptions and related art regarding self describing 
data, the reader is referred to Ludtke, et al., A METHOD 
AND APPARATUS FOR INCLUDING SELF- 
DESCRIBING INFORMATION WITHIN DEVICES, pro- 
visional application No. 60/054,327, filed on Jul. 31, 1997, 
which is incorporated herein by reference. 

It should be noted that the HAVI network of the present 
invention supports "Plug and Play" consumer appliances are 
easy to install, and provide a significant portion of their 
value to the consumer without any action on the user's part, 
beyond physically connecting the cables. This is in distinc- 
tion to existing appliances that require configuration to 
provide some major portion of their functionality. The goal 
is to offer 'hot' plug and play (not requiring the user to 
switch off appliances) where the connection method sup- 
ports it safely and reliably. 

In accordance with the present invention, an appliance 
configures itself, and integrates into a system- wide "look 
and feel" user interface, without user intervention. Low- 
level communication services provide notification when a 
new appliance is identified on the AV network. While there 
will often be settings the user may change to suit his or her 
preferences, the appliance does not require the user to do so 
in order to offer basic functionality. 

It should also be noted that the HAVI network of the 
present invention is flexible and supports multiple user 
interfaces, adapting to both the user's needs and the manu- 
facturers need for brand differentiation. In the AV network, 
protocols scale gracefully from very resource-rich, intelli- 
gent PC-like appliances to "dumb", resource starved appli- 
ances (e.g., a coffee maker or thermostat). To achieve this, 
the AV architecture allows low-end appliances to use the 
resources of more intelligent appliances in well-defined 
ways. In a similar manner, the AV architecture allows the 
specification of aggregate appliances where an abstract 
appliance is created from a logical collection of several 
lower- level appliances. 

And additionally, it should be noted that the HAVI net- 
work of the present invention supports existing standards. 
The HAVI network is complementary to several existing, 
well known, industry standards and technologies including: 
CEBus; Home Plug and Play; EHSI; VESA; Home 
Network, DAVIC, CoMMeND, Lonworks, USB, IEEE 
1394, etc. Accordingly, one goal of the present invention is 
to provide an infrastructure into which existing devices can 
fit. 

THE SYSTEM MODEL OF THE HAVI 
ARCHITECTURE 

With reference now to FIG. 1A, a HAVI network 10a in 
accordance with one embodiment of the present invention is 
shown. As described above, the HAVI architecture supports 
a wide range of devices including intelligent receiver/ 
decoders (IRDs), for example, the set top box 301, digital 
video tape records (DVTRs), video cassette recorders 
(VCRs), personal computers (PCs), digital video disk play- 
ers (DVDs), etc., communicating via a common messaging 
system. FIG. LA illustrates the physical port-to -port con- 
necting configuration 10a of an exemplary HAVI network. 
CE devices ("devices") 12-24 are shown connected together 
with bus segments 30a-30/. In one embodiment of HAVI, 
the IEEE 1394 serial communication bus standard is used as 
a platform to provide the common messaging system. 
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FIG. IB illustrates a logical bus configuration 10Z> of the 
HAVI network of FIG. 1A. As shown in FIG. IB, all of the 
devices 12-24 of the HAVI network can be viewed as 
logically coupled to a common IEEE 1394 serial commu- 

S nication bus 30. Within this bus configuration 10£, peer- 
topeer device communication is supported. For example, as 
shown in FIG. 1C, any device (having appropriate 
capabilities), e.g., device 12, can send or receive commu- 
nication packets from any other device in the HAVI network. 

10 In the example of FIG. IB, the set-top -box (e.g., an IRD) can 
receive messages from or generate messages to any of the 
other devices 14-24 of the HAVI network. 

Referring still to FIGS. 1A and IB, as described above, 
the interoperability model in HAVI provides for the follow- 

15 ing: 1) support for existing devices; 2) a default control 
model; 3) a means to extend the default control model when 
new devices or functionality is brought to market; and 4) a 
common means for device representation (e.g., graphics user 
interfaces). To achieve the above, the HAVI architecture 

20 defines three types of nodes in the home network: Full AV 
nodes (FAV), Intermediate AV nodes (IAV) and Base AV 
nodes (BAV). 

A Full AV node is a device that contains a complete 
instance of the AV software model (described in detail 

25 below). This type of node generally has a richer set of 
resources and is capable of supporting a complex software 
environment. The primary distinguishing feature of a FAV is 
that it is able to take control responsibility for less sophis- 
ticated devices and does this by loading a control module, 

30 usually from the less sophisticated device, and executing it 
locally. Examples of such nodes would be Set Top Boxes 
(e.g., set top box 301), Smart TVs, general purpose home 
control devices, or even Home PC's. 

35 Intermediate AV nodes are generally lower cost devices 
that have limited resources. They do not provide an execu- 
tion environment for control modules and so can not act as 
master controllers within the home network. Because they 
have limited resources, they can access remote resources in 

40 one of two ways: by working with other IAV devices who 
provide some capability they lack, or by using an FAV node 
which supports a control module to control them. In this 
second mode of operation they rely on full AV nodes to 
provide such facilities as a display device, general purpose 

45 compute resources and some overall control framework. 
This allows Full AV devices to bind a variety of intermediate 
AV devices together to provide a service or abstraction to the 
user. 

Base nodes are nodes that are neither FAV or IAV nodes. 

50 These are two generic types; Legacy base nodes, and other 
base nodes. Legacy base nodes are devices that were built 
before the advent of the HAVI architecture. These devices 
often use proprietary protocols for their control, and quite 
frequently have a simple, well defined, control only pro to - 

55 col. Such devices can work in the HAVI network but require 
that a Full AV node act as a gateway. Communication 
between a Full or Intermediate AV node and legacy devices 
requires that the Home AV commands used in the HAVI 
architecture be translated to and from the legacy command 

60 protocol. Other base nodes are devices that, for business or 
resource reasons, choose to implement future proof behavior 
using uploadable control software and do not carry any of 
the HAVI architecture or the message communication sys- 
tem. These devices will be controlled by an FAV node with 

55 a private command protocol between FAV and BAV node. 
With the exception of legacy nodes, each node has, as a 
minimum, enough functionality to allow it to communicate 
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with other nodes in the system. During the course of 
interaction, nodes exchange control and data information to 
enable devices to inter-operate and will do so in a peer to 
peer fashion. This ensures that, at the communication level, 
no one device is required to act as a master or controller for 
the system. However, it also allows a logical master or 
controller to impose a control structure on the basic peer to 
peer communication model. Services in the HAVI network 
are provided by one or more nodes communicating amongst 
themselves to deliver a service to user or an application. 
Where it is necessary for a node to interact with a user, then 
the node negotiates with other nodes to access and use a 
display device. 

Additionally, it should be appreciated that a distinction is 
made between Logical and Physical nodes. A good example 
of this distinction can be found in a normal TV set. Although 
the TV set is generally one physical box, it contains several 
functional components, e.g. the tuner, audio output etc. 
From the system point of view a physical node is an 
addressable peer node in the system. If the TV is constructed 
in such a way that its individual functional components are 20 
individually addressable, then it is logically one node and 
physically several nodes. Conversely, if it is constructed to 
have one addressable entity, then it is both a single logical 
node and a single physical node. 

The IAV devices and FAV devices communicate by send- 25 
ing messages over the home network using a generic mes- 
sage passing system. When new devices join the home 
network, they are recognized and added to a global name 
database (registry). The registry holds information about 
their characteristics and provides a reference to a handler for 30 
that device. Other devices and services are able to query the 
registry to locate a device and then using the handler, can 
interact with the device. For additional descriptions and 
related art regarding the communication and identification 
processes of the present invention, the reader is referred to 
Ogino, et al., "METHOD AND SYSTEM FOR PROVID- 
ING A DEVICE IDENTIFICATION MECHANISM 
WITHIN A CONSUMER AUDIO/VIDEO NETWORK", a 
U.S. patent application filed on Jan. 6, 1998, which is 
incorporated herein by reference. 

When a device is initially added to the home network, the 
system queries the device to ascertain its characteristics and 
capabilities. Once a device's characteristics are known, the 
architecture provides two methods of controlling it. The first 



device, a standard device description structure is provided 
called the self describing data (SDD) structure. The SDD 
data structure is extensible. It can be a small number of bytes 
describing the device type, e.g., TV, or VTR, etc. 
Alternatively, the SDD data structure can be a more complex 
structure also defining the override DCM and a graphical 
representation of the device. The graphical representation 
within the SDD data structure allows an FAV node to present 
a pictorial representation of the devices in the home network 
to users. By defining the graphical representation in a 
sufficiently generic manner, a device's SDD graphical data 
can be used in any vendor's product to display a user 
interface for that device. This provides an enhanced level of 
vendor interoperability and also allows a vendor to differ- 
entiate a product while maintaining within the general look 
and feel of the display device. This enables a control device 
(the FAV node) to present a general control user interface for 
all devices in the home network, irrespective of the differ- 
ences in type and vendor. 

As described above, Legacy devices are devices that were 
built before the HAVI architecture or devices that select not 
to use HAVI. HAVI supports Legacy devices by providing 
Legacy DCMs to provide protocol conversions for Legacy 
devices. These Legacy DCMs can contain sufficient knowl- 
edge to allow them to support an existing 1 or 2 way control 
protocol and provide a specific control interface to the 
devices that conform to HAVI. A legacy DCM acts as a 
bridge between the Legacy and HAVI devices. This 
approach allows HAVI also to interact with any future 
3 q device control protocols such as protocols being used for 
home energy management or security. 

It should be appreciated that the communications hard- 
ware and protocols used by the HAVI architecture are 
non-specific. The HAVI architecture is readily suited to the 
35 incorporation and use of any one of several communications 
mediums, with the simple requirement that the medium 
provides a generic communication mechanism that supports 
the HAVI interfaces. The basic model assumed is one of a 
logical communications back plane (e.g., IEEE 1394). All 
40 AV devices are assumed to be connected to this back plane, 
and can locate and communicate with all other AV devices, 
as shown in FIG. IB. In a physical setting, it is likely that 
this logical back plane will consist of more than one physical 
communication medium. It is further assumed that multiple 



method, level 1 interoperability uses a predefined message 45 protocols may be in use on different physical media. The 



set. All IAV and FAV nodes can use this command set to 
access and control other devices (BAV nodes, because they 
are deployed before the architecture was defined, are con- 
trolled using legacy protocols). The provides a default level 
of control. The FAV nodes act as control nodes and create a 
local representation of the IAV node, known as a device 
control module (DCM) that provides an API used to send 
control commands to the device. 

Level 2 interoperability within. HAVI goes farther and 
supports future added functionality and new devices. To 
achieve this, a particular device can carry within its ROM, 
an override DCM that is uploaded from the IAV device, to 
the FAV device and replaces the default DCM for the 
particular device. This override DCM not only contains the 
basic level 1 command set for the particular device but also 
includes vendor specific commands to control advanced 
features of the device. The model allows the device to 
inform another about its particular functionality. Since the 
override DCM may be loaded onto any vendor's FAV, the 
format of the DCM is architecture -neutral. 

To allow one device to discover the capabilities of another 
device and to determine which command set to use with that 



Home AV architecture abstracts above all of this and pre- 
sents a generic model of communicating nodes. It will 
provide a mechanism above the Transport layer 
(functionally like a socket) to ensure network transparency. 
50 This mechanism can be described as "reliable, ordered 
datagram service" which will provide all fragmentation and 
re -assembly. 

Accordingly, a goal of the present invention is to support 
each and every physical bus the same, such that an appli- 

55 cation need not care which physical transport it is using. 
However, with the familiarity of IEEE 1394 in the electron- 
ics industry, features of the present embodiment are illus- 
trated and described in view of functioning with IEEE 1394. 
Other buses such as CEBus and USB may not require all the 

60 same features. 

Referring now to FIG. 2, an exemplary peer to peer, two 
IAV node HAVI network 200 in accordance with one 
embodiment of the present invention is shown. HAVI net- 
work 200 includes a first IAV 201 (e.g., a television) coupled 

65 to a second IAV 202 (e.g., a receiver). IAV 201 and IAV 202 
behave in a peer-peer manner, arbitrating for necessary 
resources amongst one another. They lack the resources to 
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support the addition of a BAV or LAV device, but can included in the set-top -box 301 is a bus interface unit 608 for 
perform meaningful activities within their context. The LAV interfacing with the local bus 30 (e.g., an IEEE 1394 serial 
is not required to provide any standard UI capability. There bus). Set-top-box 301 can operate under a variety of differ- 
is no provision in the AV Architecture for "forward com- ent operating systems (e.g., Windows operating system, 
patibility" or discovery of new functions (e.g. IAV 201 only 5 DOS operating system, Macintosh O/S), but in the present 
knows the functions that IAV 202 supports based on SDD embodiment the Aperios operating system is used, 
provided upon connection of IAV2). However, in accor- 
dance with the present invention, the features of the SDD ™ E HAyi SOFTWARE MODEL 
can be easily exploited to perform "ad-hoc" feature discov- In accordance with the present invention, the computa- 
erv - 10 tional units of the HAVI architecture (e.g., DCMs) are 

FIG. 3 shows a single FAV cluster HAVI network 300 in modeled as objects. Each object is a self contained entity, 

accordance with one embodiment of the present invention. accessible through a well defined interface and executing 

HAVI network 300 includes an FAV 301 (e.g., a set top box) within a well defined software execution environment. The 

respectively coupled to a first LAV 302 (e.g., a television) a software execution environment (e.g., set top box 301 from 

second LAV 303 (e.g., a VCR) and a BAV 304 (e.g., a digital ^ FIG. 6) provides a set of well defined services (locally or 

camera). In HAVI network 300, FAV 301 controls Legacy remotely) that are also modeled as objects and can be 

and Base AV devices (e.g., devices 302-304), providing accessed, using the communications infrastructure, via their 

cluster- wide services. well defined interfaces. 

FIG. 4 shows an FAV cluster integrated with an IAV peer Each object is uniquely named. No distinction is made 

to peer HAVI network 400. In accordance with the present 20 between objects used to build system services and those 

invention, the configuration of HAVI network 400 provides used for application services. All objects make themselves 

support for legacy devices 302 and 303 while enabling known via the registry. Objects in the system can query the 

independent control to occur within the two IAV devices 401 registry to find a particular service or device and can use the 

and 402 when their resources are not in use by the FAV result of that query to send messages to that service or 

device 301. The IAV devices 401 and 402 behave as peers 25 device. The identifier assigned to an object is created when 

to the FAV device 301. For efficiency, a resource conflict the object registers. This identity, if required, is guaranteed 

policy can be implemented for both FAV to FAV or FAV to to be persistent during the lifetime of the object and will 

IAV resource requests. The IAV will be controlled by the remain persistent even in the face of a complete reboot of the 

FAV by via a DCM running in FAV 301. home network. 

FIG. 5 shows an exemplary HAVI network 500 having In accordance with the present invention, the objects 

multiple FAVs. HAVI network 500 includes an additional communicate using a message passing model. An object that 

FAV 501 (e.g., a satellite receiver). This configuration wishes to use the service of another object, does so by using 

behaves in a similar manner to HAVI network 400 described a general purpose message passing mechanism that delivers 

above. In this configuration, the FAV devices 301 and 501 35 the service request to the target object. The target object is 

act as peers. specified using the unique object identifier discussed above. 

While in the present embodiment the message passing 

THE COMPUTER SYSTEM PLATFORM mechanism functions with IEEE 1394, it should be noted 

With reference now to FIG. 6, a diagram of a set top box that there is 110 distinction between sending a message across 

301 in accordance with one embodiment of the present 40 a 1394 bus > or over a Contro1 M iink - In the same manner, 

invention is shown. As described above, any consumer mere is no distinction between objects on the same node and 

electronics device can be a FAV and thereby provide a one on a remote node. The actual implementation of the 

computer system platform for HAVI software. For instance, message passing infrastructure will depend on the system 

the set-top-box 301 device of the exemplary HAVI network and networking environment and will differ from node to 

contains special components that provide an operation plat- 45 node aad between vendors. However, the actual format of 

form for software components of the HAVI architecture the messages must be common so that interoperability is 

which are described below. Specifically, aspects of the assured. 

present invention, described below, are discussed in terms of It should be appreciated that the general intent of the 

steps executed on a computer system (e.g., processes shown object model and messaging system is to provide a com- 

in FIGS. 13 through 17 A). Although a variety of different 50 pletely generic software model that is sufficiently flexible to 

computer systems can be used with the present invention, an allow multiple implementations with a variety of software 

exemplary general purpose computer system is shown in the systems and languages. Details of the binding between 

set-top -box of FIG. 6. messages and the code that handles them are left to the 

Set-top-box 301 of FIG. 6, in addition to having a s y s( em implementor. 

video/audio receiver (decoder) unit 606 and MPEG unit 60 7 55 SOFTWARE ARCHITECTURE OVERVIEW 
also includes an address/data bus 600 for communicating 

information, one or more central processors 601 coupled The HAVI software architecture defines the way that the 

with the bus for processing information and instructions, a software model is used to support the HAVI architecture. In 

volatile memory 602 (e.g., random access memory RAM) particular it defines the way that devices are abstracted and 

coupled with the bus 600 for storing information and 60 managed within the AV architecture. It defines the ways that 

instructions for the central processor 601 and a non -volatile interoperability is assured, and it defines the ways that future 

memory 603 (e.g., read only memory ROM) coupled with devices and services can be integrated into the architecture, 

the bus 600 for storing static information and instructions for Full AV nodes as software managers: In accordance with 

the processor 601. Set-top-box 301 can also optionally the present invention, Full AV nodes (FAVs) act as managers 

include a data storage device 604 ("disk subsystem") such as 65 for Intermediate (IAVs) and Base (BAVs) nodes and provide 

a magnetic or optical disk and disk drive coupled with the a platform for the services that support the HAVI architec- 

bus 600 for storing information and instructions. Also ture. To achieve this they provide an execution environment 
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which allow objects to control and communicate with ser- and IAV devices, that contains information about the device 

vices and devices. To ensure that devices are accessible and which can be accessed by all other devices. This data 

within the Home AV network, the FAV nodes support a structure is referred to as a Self Describing Data structure 

software abstraction of the services that a device offers to • (SDD). The SDD contains, as a minimum, enough informa- 

others. As described above, this abstraction is referred to as 5 tio n to allow another device to discover its basic capabilities 

a device control module (DCM). The DCM is modeled as an and so infer the basic se{ of command messages that can be 

object within the software architecture but is refereed to sent to that device and events it should reasonably expect to 

hereinafter simply as the DCM to distinguish it. The inter- receive from that device ' 

face that the DCM exposes to the rest of the system provides Th e communication process of the present invention 

the means to access and control that device. In the general 10 provides for the fact that once a device has determined the 

case, a FAV will manage a set of DCMs, one for each IAV capabilities of another device, it then needs to be able to 

node and base node in the home network or portion of the access those capabilities. To achieve that requires a general 

IAV network that it manages. Thus, it should be appreciated communication facility that allows one device to send a 

that from an interoperability perspective, the primary role of message containing a command request to another device, 

the FAV node is to manage DCMs of the present invention is 1116 general message service processes of the present inven- 

and act as an execution environment for DCMs. tion were discussed above. 

Full AV node as controller and display device: In accor- Generic message set refers to the process required to 

dance with the present invention, in most cases, FAVs will su PP ort level 1 interoperability. This includes a well-defined 

have an associated display device which is used for display set of messages that must be supported by all devices of a 

of AV content and of user interface (UI) material. However, w Particular class. This ensures that a device can work with 

the HAVI software architecture does not mandate this and other devices ' ^respective of the manufacturer, because all 

FAV nodes may be "headless". In this case they will devices t0 a common set of genenc commands. As 

cooperate-operate with other nodes to display content and bussed above, within the HAVI software architecture of 

UI information (see below). However, FAV devices will be the P resent invention, these commands are presented as a 

responsible for supporting the high level UI APIs that 25 DCM to the rest of the system. 

provide the look and feel of the entire home network. The three basic processes of the present invention 

lower level graphic manipulation APIs will generally be support at least a minimal level of interoperability. Since, in 

located close to the graphics display device itself and are most cases > an y device can query the capabilities of another 

manipulated by the FAV high level APIs via toe SDD > anv device can determine the command set 

Peer to peer architecture between full AV nodes: In a 30 SU PP orted ^ ™*™ device * And sinc * each device has 

Home AV network in accordance with the present invention, access t0 a ,f nenc then ™V device can 

there may be more than one FAV In this case, each FAV interact Wlth ^ other device " 

cooperates with other FAVs to ensure that services are . L . However ' 11 should be appreciated that level 1 compat- 

provides to the user. This allows FAV nodes to cooperate to lbdlt y m a ccordance with the present invention only ensures 

share resources. For example, an FAV node that does not 35 that devices can mter-ope rate at a minimal or degraded level 

have direct access to a display device, may use a remote FAV °f functionality. The generic message set for each device 

node to display DCM user interfaces. Alternatively, a FAV class 15 a minimal and common set of commands. The SDD 

node may require the services of a data translation module fadlitv ° ffers a means to P rovide some de g ree of customi ' 

that exists on a remote node to allow it to set up a data route zatl0n of a device bv Providing information about its UI and 

between two AV devices 40 some ^P^^ °f n* s interaction model. Other IAV devices can 

use this information to present an interface to the device. 

LEVEL 1 AND LEVEL 2 INTEROPERABILITY Alternatively, any FAV device can use this information to 

GENERALLY customize the generic DCM it has created for the device. 

However, it should be noted that a more extensible media- 

In accordance with the present invents 45 nism ^ a]so necded to alk)W a dcvice tQ commas ^ iic to 

goals of the HAVI architecture of the present invention is to Qther devices additional wionality it posses. Level 2 

support interoperability between devices. This includes interopcrability of the presen t invention provides this 

existing devices and future devices To achieve that mechanism . Uvel x and Uvel 2 interoperability are dis- 

interoperabihty, the HAVI architecture of the present inven- cus&ed [a &Q . diCT detail bebw 

tion supports a general model that allows two levels of 50 

interoperability, these levels are referred to as Level 1 and LEVEL 1 AND LEVEL 2 DCMs 

Level 2. As described above, the DCM of the present invention 

Level 1 interoperability: Level 1 interoperability of the functions by providing access, control and interaction with 

present invention addresses the general need to allow exist- a device. DCMs are typically instantiated (e.g., executed) on 

ing devices to communicate. To achieve this, level 1 in terop- 55 the resources of FAVs in the Home AV architecture. The 

erability of the present invention defines and uses a generic DCM of the present invention provides an interface to a 

set of control messages (commands) that enable one device device and manages a UI that the device wishes to present 

to talk to another device and a set of event messages that it to users. 

should reasonably expect from the device. To support this In accordance with the present invention, with the level 1 

approach a basic set of processes are required. These pro- 60 interoperability, the DCMs created for devices are generic, 

cesses include device discovery, communication, and a They support a minimal command set that allows generic 

generic message set. control of the device. To support device specific features 

The device discovery process of the present invention requires that the DCM provide access to such device specific 

provides for the fact that each device in the Home AV features and is capable of presenting device specific features 

network needs a well defined method that allows it to 65 to users via the UI. 

advertise to others its characteristics. The approach we have To achieve this, Level two interoperability is used. In 

adopted is to specify a data structure, required on all FAV accordance with the present invention, the Home AV archi- 
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tecture allows a device to provide an "override" DCM for nent (as opposed to a hardware device) that provides a 

the generic DCM that would normally be created for that general service to other devices or components in the home 

device. The override DCM (e.g., level 2 DCM) is capable of network. 

replacing the default DCM (e.g., level 1 DCM) on the FAV Comms Media Manager 740: This component is respon- 

It should be appreciated that the level 2 DCM could be s sible for managing the underlying physical communications 

retrieved from a variety of sources. One such source is the process. It provides an API that allows code modules to 

SDD of the device itself. In this case, the level DCM is interact with the features of the communications media (e.g., 

fetched, received, or otherwise acquired from the SDD of IEEE 1394). 

the device and instantiated in an FAV node when the device Registry 706 . ^ fe a ^ ice database< DCMs for 

is installed into the system. Because the Home AV archi- 10 physical devices and software services will register them- 

tecture is vendor neutral, it is necessary that the level 2 DCM selves in the registry 706 and all modules ( e . g>> device 

work on a variety of FAV nodes, each with potentially modulcs 720) can query the registry t0 get a handle for 

different hardware architectures. To achieve this, the format another device or module. 

of both the level 1 and level 2 DCMs of the present invention ^ . - rn , 

. . , . , • j . 4 c Communications manager 750: This component is a low 

are architecture neutral such that a wide variety or software 15 , , , . c t , ° ... r J . 

, t_i . • . level abstraction of the communications media, 
execution environments of the FAV nodes are able to instan- 

tiate and run the level 1 and level 2 DCMs. Messaging 702: This component provides a basic mes- 

Ti , , , , • i j i ' j iL sa 2 e passing facility to allow both devices (hardware) and 

It should be appreciated that, in accordance with the j • j i j • j. i -i \ , 

t . j • j .... r,.,, device modules 720 and service modules 730 to communi- 

present invention, once created and running within a FAV , ... . t . 

j .« t^^, V. . . & . . ... nn cate with each other. 

node, the DCMs or the present invention communicate with 20 ¥ ^ w mM __ . 

the IAV and BAV nodes in the same manner as described tvent !^ ana 8 e 703: 11115 module Provides a generic event 

above using the basic messaging mechanism. s = rvlcc " ^ 15 . a «w-to-iMiiy commumcaticn service 

...... A r^^r allowing notification in the HAVI network. 

As described above, there are many permutations of FAV, 

IAV and BAV nodes possible within a given HAVI network. Initiation manager 701: This component is used as 

These permutations generally fall into two types: HAVI 25 P art of the device bootstrap process, 

network configurations that support an FAV device, and Data rowing 762: The data routing component 702 is 

those that do not. This distinction essentially defines whether responsible for helping services set up routes between 

a HAVI network will be using a peer to peer configuration devices and devices modules. It takes into consideration the 

(e.g., as shown in FIG. 2, where no FAV is present) or will <cost ' of transferring data via a particular route, the require- 

be imposing some form of control hierarchy (e.g., the FAV 30 menls on data format translation etc. This component is not 

cluster as shown in FIG. 3). needed for the basic architecture. 

In accordance with one embodiment of the present AV Actions/Macros 763: this component is a manager for 

invention, in the cases where no FAV is present, only level higher level AV actions which are groups of individual low 

1 interoperability is available and the devices are forced to level commands, i.e. it provides a macro service. This 

use SDD information to discover other IAV capabilities, 35 component is not needed for the basic architecture, 

present those capabilities, and control the device. In the High level UI library 704: This component provides a set 

cases where FAVs are present, DCMs are instantiated and of high level UI components that are used by device modules 

uses. If these are level 1 (e.g., generic) DCMs, the devices 720 to build UIs for their corresponding devices. This 

are operating at level 1 interoperablity. If there is at least one component is not needed for the basic architecture, 

level 2 DCM present, then some of the devices are operating 40 Application (and User) interface 705: This component 

at level 2 interoperability. provides the linkage between a common consumer electron- 

In accordance with the present invention, it should be ics platform (CCEP) APIs of the HAVI compliant devices 

noted that a mixed mode of operation is possible in which and applications which are local or possibly remote. This 

clusters of devices are inter-operating under control of an 45 component is not needed for the basic architecture. 

FAV node, while other devices are inter-operating in a peer It should be appreciated that the above components as 

to peer fashion. In this manner, the flexibility of the present diagrammed in FIG. 7 are abstractions of functionality. They 

invention allows vendors the freedom to design and build are designed to make clear what functionality is included in 

devices ate all points on the cost/capability spectrum with the architecture for HAVI compliant devices. In order to 

the certainty that these devices will inter-operate seamlessly 5Q avoid unnecessarily obscuring the present invention, the 

with other devices in the HAVI network. relationship between components 701-763 and the message 

Referring now to FIG. 7, a logical block diagram 700 of flows between them are not shown, 

one embodiment of the HAVI architecture is shown. FIG. 7 DCM CONFIGURATION AND FUNCTION 

shows an overall HAVI architecture in accordance with the Overview 

present invention. The components shown in diagram 700 5S In one embodiment of the present invention, in HAVI 

are as follows: network configurations where a FAV node is available, a 

Device manager 761: Device manager 761 is responsible DCM exists for each physical device in the HAVI network 

for creating and managing the DCMs that represent devices known about by that FAV node. The DCM provides an 

managed by an FAV device. interface to the device and presents it as an object in the 

Device Modules 720: These are the DCMs for individual 60 architecture. Other DCMs, system services or application 

devices. As described above, each DCM functions as a services can query the local registry to find out the devices 

control point for a device and provides a UI component and available and to get an identifier to allow them to interact 

a control component. The DCMs (e.g., device modules 720) with the devices via its DCM. 

provide an API to allow other applications to access and Device control modules are also responsible for interact- 

manipulate the devices. 65 m g with the software architecture to present the device user 

Service Modules 730: These modules can be viewed as interface (UI) to the user. Input from users is then passed to 

software devices They are DCMs for any software compo- the DCM which uses the input to control the actual device. 
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As discussed above, DCMs support the level 1 and the 
level 2 interoperability. A level 1 DCM is a generic DCM, 
usually supplied with the FAV node, and capable of man- 
aging a basic, pre-defined set of features of a device class 
using a pre-defined message set. During initialization, the 
DCM will work with the Device manager (below) to dis- 
cover the actual characteristics of the device to be managed, 
and will configure itself to control that device. Thus a 
generic VCR controller could be instantiated to control a 
standard VCR using either 1394 AV/C messages, or via 
Control Al . 

In the case of level 2 interoperability, the DCM instanti- 
ated for that device will be an override DCM that has been 
loaded from an external source, e.g. the device itself. These 
override DCMs are written in the common language format 
for DCMs. The functioning of an override DCM doesn't 
differ from generic ones but the API offered is likely to be 
more comprehensive. 

Once instantiated, DCMs will provide not only control 
interfaces for the device, but also access to SDD data 
associated with a device. They will act as event managers for 
a device, receiving device specific events and posting those 
to the event system (see below). They will also act as UI 
manager for the device, interacting with the UI management 
system to provide a user interface via some display device. 
Lastly, the DCM will operate as a resource manager for 
devices, arbitrating requests made for device access and 
service. 

General DCM Terminology 

In the terminology of the present invention as used in the 
following descriptions, each DCM presents a model of a 
device in the home network. The basic terminology used is 
as follows: 

1) Device: This term refers the entire device. 

2) Subdevice: This term refers to one of possibly many 
components that make up a device. Some technologies do 
not have the ability to distinguish subdevices. 

3) Internal Connection: This term refers to the logical or 
physical connection between internal subdevices. 

4) External Connection: This term refers to the connection 
between a physical connector on the outside of a device and 
a destination device outside the device. The same as unit 
Serial Bus and external input and output plugs for AV/C. 

5) Protocol: This term refers to the control protocol 
spoken by the sub-device or device (e.g., AV/C, Control Al, 
etc.). It should be note that a device may contain subdevices 
which speak different protocols. 

6) Interface: This term refers to the physical bus connec- 
tion interface (1394, USB, etc.). 

7) Device Class: This term is one way to describe the 
basic functionality of a given collection of devices. For 
example, the class of DVCR devices can record data to a 
tape medium. Likewise, there may be many devices that can 
take audio input, perform some kind of special effects, and 
output the modified audio stream. These would all come 
under the class of audio processor or something like that. 
The usefulness of this concept will become more apparent 
later in the document. 

8) Device Model: This term refers to the collection of 
subdevices and connections that make up either a standard 
or custom device definition. Individual subdevices that are 
accessible within physically separate devices can be com- 
bined to form logical or virtual devices using the device 
model. 

9) Standard Device: This term refers to standard model 
definitions (e.g. a DVCR device is composed of at least a 
tuner subdevice and a VCR (transport) subdevice, with plugs 
between them). 
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10) Special Device: This term refers to a vendor-specified 
device model, composed of either standard subdevices or a 
combination of standard and vendor-specific subdevices. 
For example, a dual deck DVCR may have two VCR 

5 subunits, which are standard items, but in a non-standard 
configuration. 

11) Aggregate devices: This term refers to logical entities 
which can be combined from a variety of components. 
Physical devices and subdevices are individually accessible 

10 pieces of hardware. When devices have accessible 
subdevices, this model is extended to support aggregate 
devices. Examples of aggregate devices include subdevices 
from separate physical devices or within a single device, and 
software modules such as software codecs which provide 

15 services or capabilities similar to devices and subdevices. 
These modules can all reside in the same node on the AV 
network, or can be distributed among many nodes.. 
Device Classification 

Classifying devices based on the kind of actions they 

20 perform, or the kind of medium they deal with, is a way of 
allowing us to create a generalized control API that will 
work for devices that are created in the future. The intent is 
to allow a high percentage of basic functionality to always 
be accessible regardless of the type of device or the manu- 

25 facturer of the device. 

Any manufacturer-specific or device-specific functional- 
ity that is controllable as well but falls outside of the 
generalized control API will only be accessible via the SDD 
information and other techniques for extending a DCM. 

30 In the most general terms, the classification of devices or 
subdevices can be described by their main functionality. The 
AV/C control protocol of the 1394 standard uses a conve- 
nient method of classifying devices which we have adopted 
below. Following is the first set of factors used for classi- 

35 fying a device or subdevice: 

1) Whether a particular device has a transport mechanism. 

2) Whether the usefulness of this subdevice defined 
mostly by the fact that a signal ends up here (regardless of 
the fact that it may be propagated without changes). 

40 3) Whether a particular subdevice a signal source (e.g., 
does it have a signal output). 

4) Whether a particular device accepts input, performs 
some sort of processing, and then outputs modified data. 

5) Whether there is no signal input or output of any kind 
45 (e.g., is the device a utility of some kind, such as a 

mechanism for positioning a satellite antenna). 

In accordance with the present invention, at a second level 
of classification, we can study devices that contain a trans- 
port mechanism. In this case, a general question would be 

50 "does this device deal with removable media?". If it does, 
then a basic set of controls is applied, such as Play( ), Stop( ) 
and even Search( ). Devices with media can be queried for 
their ability to record, to determine the organization of 
information on the medium (is it track-based? continuous 

55 such as a tape? how is it measured — SMPTE time codes, 
lime offset from a certain position, etc.). 

In the present embodiment, a signal processing service 
can be described by the kind of signal(s) it can accept, and 
the kind it can produce as a result. This requires the 

60 establishment of common definitions for describing signal 
types and methods for accessing the services, so that any 
client can know how to describe what kind of service it is 
looking for, and how to access that service. 
Any device which accepts one kind of data and has the 

65 ability to transmit that data on a different type of connection 
(for example, it takes digital video as input and has standard 
analog video RCA jacks which can send that data back out) 
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can act as a data converter class. The DCM for these devices 
will register itself as a data converter in the system registry, 
so that clients can find them and use them as necessary. 
Device Access and Control 

In accordance with the present invention, once a basic 5 
device classification has been made, then the generic DCM 
instantiated for that device will provide an API that causes 
control messages to be sent to that device. The base set of 
control messages that can be sent or received (in the case of 
events) to a particular class of device are standardized and 10 
detailed in the appendix (not available in this version of the 
document). In the present embodiment, these messages 
represent a basic API presented by the DCM. 
Device Management 

In accordance with the present invention, the DCM API 
also provides a set of higher level services that allow more 
sophisticated management of the device. Examples of this 
include device reservation and event management. In the 
case of device reservation it is likely that a request for a 
device may be refused due to existing requests on the device, 
alternatively, the device request may be for a future reser- 
vation for a time based macro. In these cases the DCM 
provide an interface to allow an application or service to 
queue requests with the DCM, i.e. reserve a device, or to 
receive notification when a device becomes available. 
Connection Management 

The DCMs of the present invention also provide a high 
level API to allow other objects to query the state of 
connections between devices and to manipulate those con- 3Q 
nections. This API is primarily used by the Route manager 
but is available to any object in the system. Connection 
management allows connections to be established, both 
internally between subdevice units, and externally between 
devices. Connection status can be queried and connection 35 
capabilities (signal formats) can also be queried. SDD 
management 

The DCMs of the present invention also provides a 
generalized interface to SDD management. This allows the 
SDD data in the device to queried and used. The API is 4Q 
divided into two parts, part 1 provides APIs for getting well 
know information from the SDD data including the 
Devicelmage, its name and the URL (if available) of a 
location for an override DCM or other icons to be used in 
representing the device's UI. Part. 2 of the SDD API is 45 
designed to provide more detailed access to functional 
aspects of the device. 

Device Representation and User Interface (UI) 

In accordance with the present invention, the DCM is also 
responsible for the UI aspects of the device. In the case of 50 
level 1 interoperability, a generic UI is used to interface with 
users. This may be augmented by basic SDD data that allows 
such aspects as UI icons to be specified and accessed by the 
generic DCM. In order to avoid unnecessarily obscuring the 
present invention, the details of how the DCM interacts with 55 
the UI management system to present a device specific UI is 
not discussed in detail. In the present embodiment, however, 
the basic model is that internal management code within the 
DCM works with the UI management system to present a UI 
for the device. User input is then forwarded by the UI 60 
management system, to the DCM which then converts it into 
device specific commands/These commands are sent, using 
the basic messaging system, to the device. If replies are 
received then these are passed via the DCM up to the UI. In 
addition, any status changes of the device, e.g. on/off are 65 
also passed, via the event system to the DCM which uses 
them to update the UI. 



Service Modules 

Service modules (e.g., service modules 730) are concep- 
tually similar to device control modules. They provide an 
interface to a service which is usually provided by software 
only. In the present embodiment, service modules are of two 
types, system services and application services. A system 
service is a well know service that is provided as part of the 
HAVI software architecture. Examples of these types of 
services are data format translators, protocol converters or 
graphics services. These services have well known APIs 
which are defined as part of the HAVI architecture. Appli- 
cation services are objects that have been created for and by 
other service objects. These objects provide a well defined 
API, however that API is not public. In the present 
embodiment, any application or other object that wishes to 
use an application object needs to know its API and calling 
semantics. Although not required, generally, system services 
will exist for the lifetime of the system. Application services 
will exist for the lifetime of an application and may be quite 
short lived. 
System Services 

In accordance with the present invention, many of the 
services provided by the AV architecture are provided as 
service modules, who register their services in the system 
registry and can be accessed using messaging. Examples of 
such services are the UI service modules that provide a 
mechanism to allow devices to present a UI to the user, data 
format services that convert AV data between different 
formats. 

THE DCM MANAGER 

Overview 

In accordance with the present invention, the DCM Man- 
ager is responsible for all aspects of handling the collection 
of DCMs resident on a FAV node. This includes the tasks of 
discovering, instantiating and disposing of all possible 
device control module candidates that are available to a 
given system. Device resource management is generally 
carried out by individual DCMs, however, where multiple 
devices or services are interacting and where some of the 
DCMs are located on different FAV nodes, higher level 
management will be needed. Therefore, the DCM Manager 
communicates with other DCM Managers on remote nodes 
to arbitrate for network-wide device and subdevice resource 
allocation and management. Its responsibilities are dis- 
cussed below. 

Discovery and Enumeration of Physical Devices 

In accordance with the present invention, the DCM Man- 
ager works with the underlying OS services to obtain a raw 
list of available devices. Note that depending on the under- 
lying bus technology, these DCMs may be dynamic. In the 
present embodiment, for example, as physical devices come 
and go on a 1394 bus the DCMs will come and go with them. 
In the same manner, the service and aggregate device DCMs 
are also dynamic, being created and destroyed in response to 
events in the FAV node. 

This task requires interaction both with elements of the 
AV architecture and also with elements of the FAV host OS, 
node hardware and communications hardware. Due to this, 
the exact process required for device discovery will depend 
on the system environment. However, the general approach, 
of querying a device and any SDD data it contains to 
discover its characteristics, as discussed in the DCM section, 
is common. In the present embodiment, this requires the 
DCM manager to follow a set of rules in a given sequence 
each time the system is initialized, or any time the system 
may change (such as when the bus is reset). 
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Creation of Generic DCMs tion is shown. The components shown in diagram 800 are 
In accordance with the present invention, for each node, similar to those shown in diagram 700, however, diagram 
the DCM Manager does enough work to determine that it 800 is organized such that high level processes are on top 
should create a DCM. This work is carried out for all (e.g., applications 801) with respect to lower level processes 
media-related devices which will be managed by the FAV 5 on the bottom (e.g., 1394 module 830). Diagram 800 also 
node. In the present embodiment, Devices under a different depicts other ^iccs 810, transportation adaptation mod- 
management technology, e.g. USB based devices, may be ules 815 and other modules 840 , 

presented within the architecture as DCMs on nodes that ^ described abovC( thc ovcrall HA VI architecture can be 

support USB communication, or as specia DCMs that act as showD ^ communications comp0 nents and service compo- 

proxies for a remote management system. It should be noted, Applications 801, at the highest level in the architec- 

however, that some USB-based devices such as hard disks 4 \v ^ *u - 

may in fact be made to appear simply as random-access ure ™ es and the communication components 

media recording or playback devices; in these cases, they are ^> DC f* 720 ' ^ m modules ™> etc <); In tu ™; a 

treated like any other "real" media device. In the present number of the semc « components (e.g., service modules 

embodiment, for each media-related entity, the DCM Man- 730 > DCMs 720 > etc > wil1 use the underlying communica- 

ager will create a generic or level 1 DCM. Each DCM will 15 tl0ns components (e.g., messaging 702, transportation adap- 

later have the responsibility to make itself more device- ta tion modules 815, etc.). For example, in the case of one of 

specific if possible. This is described below. applications 801 requesting, via the registry 706, the handle 

Integration of Level 2 DCMs for a DVTR (digital video tape recorder) device, and then 

In cases where an over-ride (e.g., level 2) DCM is sending a play command to the device. As described above, 

available and accessible, the DCM manager is responsible 20 components in the HAVI architecture communicate using 

for attempting to fetch that DCM and installing it into the the underlying messaging system, i.e. the modules use 

FAV node. In the present embodiment,, the details of how message passing. 

the over- ride DCM and the generic DCM interact is depcn- FIG. 9 shows a diagram 900 of local and remote mes- 

dent on the DCM developer. For example, in some cases it saging in the HAVI architecture of one embodiment. The 

will completely replace the default DCM, in others it will 25 messaging component 702 is shown handling both local 

work with the default DCM to augment its capabilities. messaging and remote messaging. Hence the messaging 

In accordance with the present invention, manufacturer- component 702 is depicted at the base of diagram 900. Local 

supplied level 2 DCMs may come from a variety of sources. messages are shown as arrows 902a, 903(3, 904a, to various 

Devices may carry them within their ROM or some other applications 901-904. A remote message is shown as arrow 

storage mechanism such as the header of a disc or tape. They 30 901fc, For the sake of clarity, in diagram 900 and in the 

may be downloaded from a web or ftp site if such capabili- following discussions, local communication via the messag- 

ties are accessible to the FAV node, or they could be supplied ing system is not depicted, rather, local messaging (e.g., 

in the typical computer industry manner, via an installation arrows 901a-904a) are shown as if based on direct function 

from a disk or other storage medium. Allowing this calls between components. 

manufacturer-supplied over-ride DCM capability requires a 35 FIG. 10 shows a diagram 1000 of a message being sent via 

model for creating and installing DCMs. In the present 1394 in the HAVI architecture of one embodiment. In 

embodiment, when installed, the level two DCM will pro- diagram 1000, message 1 (e.g., arrow 820a) is a request 

vide the same base interface to the client as a level 1 DCM, from one of applications 801 to the registry 706 (via the 

while either providing additional interfaces or just underly- query API) for the handle of a D VTR device. The registry 

ing functionality modifications. 40 706 returns a handle for the DVTR DCM in message 2 (e.g., 

DCM Disposal arrow 8206). This handle is the message address used for the 

In accordance with the present invention, the DCM Man- messaging system, 

ager will be responsible for (disposing of DCMs at the In accordance with the present invention the application 

appropriate times, and notifying clients that DCMs have then uses the handle to invoke the DCM for the DVTR*with 

been removed. In the present embodiment, the rules for 45 message 3 (e.g., 820c). The DCM converts the application 

when DCM disposal occur, and the distribution of respon- invocation of the play call to an internal command which is 

sibility for clean up, between the DCM and the DCM sent to the messaging component, message 4 (e.g., arrow 

Manager, are tailorable to for the specific requirements of a 820<f), This internal command is part of the well defined 

particular HAVI network. command set at level 1, i.e. it is a HAVI command. The 

Coordinate Amongst Multiple DCMs 50 messaging component 702 then internally uses the handle 

Some complex services among multiple DCMs, for information to determine which bus this device resides on. 

example, command queuing of complex operations, etc., When it discovers that it is on the IEEE 1394 bus, it uses the 

require the DCM Manager to coordinate with multiple IEEE 1394 transport adaptation module (TAM) 830 to 

DCMs to carry out these operations. This will be influenced convert the message to a 1394 packet, message 5 (e.g., arrow 

by the "command model" that is provided for clients. For 55 8 20e), which is placed in the data portion of a FCP packet, 

example, if we define an upper level API that allows clients The TAM then calls the 1394 device driver, message 6 (e.g., 

to specify actions that are based on HH:MM:SS:FF time arrow 820/) to send the message over 1394. 

codes, then we need to translate between this time model and At the receiving side (not shown), the message will be 

whatever the hardware or underlying support modules deal delivered to the 1394 device driver, and then passed up 

with. It should be noted that complex time-based operations 60 through a 1394 TAM to the Messaging component. The 

that are affected by mechanical delays, etc., need to be messaging component will receive a HAVI message packet 

accounted for. This type of coordination requires some which it will then deliver to the receiving code directly via 

notion of real time behavior in the network and is dependent a message queue or callback function. In the present 

on the physical and software infrastructure providing some embodiment, if the receiving device is an IAV device, it will 

level of guarantee. 65 only have the communications component of the CCEP 

Referring now to FIG. 8, a layered logic diagram 800 of architecture and the registry. Any other functionality it has 

one HAVI architecture in accordance with the present inven- will be device specific. 
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It should be noted that the previous example in FIG. 10 been configured to manage both 1394 and Ethernet. When 

illustrates a distinction in the HAVI architecture between the the legacy device becomes know to the FAV, it will first 

messaging system and the command set used to control become known at the CMM module. Note that the mecha- 

devices. In accordance with the present invention, the mes- nismused to achieve this is not within the scope of the CCEP 

saging system is a generic messaging mechanism that pro- s architecture. It is communications media specific. Once the 

vides a message packet with a data section whose contents CMM recognizes a new device, it will go through whatever 

are completely opaque to the messaging system. For media specific mechanism it uses to determine the type of 

example, the messaging system can carry private application the device. Again this is not part of the CCEP architecture, 

to application commands, AVC-CTS commands, CALcom- Eventually it will ask the DM to instantiate a legacy DCM 

mands or any other command. The DCM is the entity 10 for this device. It is assumed that the FAV node has been 

responsible for communicating with remote devices, it uses pre -configured with this DCM. 

the messaging system to carry commands specific to that In the present embodiment, once the DCM is created, it 

device. For a level 1 HAVI compliant device, the command registers itself in the same way as any standard DCM. 

set carried by the messaging system is defined as part of the However, one crucial difference between this DCM and 

CCEP architecture. Messages carried by the messaging 15 other DCMs is that the communication model and the 

system between DCMs and devices they control contain command set used to control the legacy device is completely 

these well defined commands. For level 2 devices the unknown to the CCEP architecture. For example, it is 

extended command set is undefined, these may be pure possible that the device is an IP device that implements a 

AV/C-CTS, CAL or any other commands. printer service. In this case the DCM will provide a set of 

Referring now to FIG. 11, a diagram 1100 of an applica- 20 commands such as Print, Status etc. When an application 

tion invoking another application in one embodiment of the calls the DCM API with a print request, the print command 

HAVI architecture is shown. Diagram 100 shows an appli- will be sent out by the DCM, via an IP stack, to the printer 

cation 801 a running on a device 1101 passing a message device. The actual details of how this happens are imple- 

1105 to an application 801/? running on a separate device mentation specific. 

1102 via messaging systems 702a and 102b. As described 25 In accordance with the present invention, one possibility 

above, any application running within the HAVI network is that the legacy DCM has a full implementation of the IP 

can access any other application if it has a message handle stack within the DCM and knows how to bind to the 

for that application. To acquire a message handle, the same Ethernet device driver. Another possibility is that the FAV 

process is used as for a remote LAV device (e.g., described device provides an IP stack and a higher level API such as 

in FIG, 10 above). Once a message handle is available, the 30 sockets. These are FAV implementation details and not part 

source application 801a can send a message 1105 to the of the CCEP architecture. However, it should be noted that 

target application 801fc. As described above, the format of the legacy DCM is acting as a "proxy" DCM. Once it has 

these messages is entirely dependent on the application and been registered in the registry, it is visible to all other 

is of no concern to the CCEP architecture. It simply provides modules in the home network. They can all invoke its API 

a communication mechanism to send a receive messages 35 and it performs the necessary conversion to the private 

between the applications. command language of the Ethernet IP printer. 

It should be appreciated that in the above example, it is In the case of adding a base AV device, in the present 

assumed that the applications 801a and 801b reside on embodiment, when the CMM is informed about the new 

different AV devices 1101 and 1102. However, as discussed device, its recognizes that this is not a CCEP node, but it also 

previously, it is quite possible that these applications 801a 40 discovers that a DCM is available for this device. In this 

and 8016 will reside on the same AV device and so the case, the CMM is responsible for implementing a mecha- 

messaging system will perform a purely local communica- nism that allows it to upload the DCM and to ask the DM to 

tion call rather than a call that uses 1394 to transport the create this DCM. However, once the DCM is instantiated 

message. then it uses a purely private communication mechanism to 

Invoking a Software Service 45 access and control the device. As described above, in the 

A software service is a special case of the generic appli- present embodiment, a base AV device is one that uses 1394 

cation case above. In accordance with the present invention, and implements the over- ride DCM but does not implement 

a software service is simply an application that is part of the any of the CCEP architecture and will not implement level 

system infrastructure. In this case, when a module wishes to 1 HAVI commands. An example of this device could be one 
invoke a system service, e.g. the UI component, it uses the so that contains an over-ride DCM but does not support the 

messaging component to do this. If the UI component is CCEP communications infrastructure, 

local then the call is contained entirely within one AV In the case of adding an IAV device, it should be appre- 

device. However, if the UI component is remote, then the ciated that in the previous examples, the application queried 

call will be routed over the 1394 network to the remote AV the registry to get a message handle for the device it wished 
device, where the message system will dispatch the call to 55 to communicate with. Note that for a FAV device, the handle 

the UI system service. returned is always used to access the DCM. It is not possible 

Adding a New Device to a HAVI Network to send messages directly to the device. To understand how 

In adding new devices to a HAVI network, there are 3 a device which is added to the network becomes available 

general situations: handling a legacy device using a legacy via the registry then the following example is used, 
protocol carried over a non 1394 network; handling a base 60 For example, assume a new device (e.g., a camcorder) is 

device using a non HAVI protocol over a 1394 network; and plugged into the HAVI network (e.g., 1394 based). This 

handling a new IAV device that is HAVI compliant. causes a bus reset. The bus reset is handled by the Com- 

In the case of adding a legacy device, in the present munications media manager (CMM) on the IRD. The CMM 

embodiment, a legacy device can only be directly controlled is responsible for querying the SDD data of the Camcorder 
by an FAV node. As described above, for each legacy device, 65 device to discover its capabilities. Assuming the device is a 

a legacy DCM must be created. Consider an FAV that has a level 1 device, i.e. it does not have an uploadable DCM, then 

1394 port and an Ethernet port. The CMM module will have the CMM informs that Device Manager, that a new device 
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has been installed. The Device Manager creates a new DCM 
for this type of device and registers the DCM with the 
registry. The DCM, when it initializes is free to query the 
device directly to find out more information about itself and 
to specialize itself if needed, e.g. it can access UI informa- 
tion if it exists in the device. Once the DCM is registered in 
the registry, then any other module can query the registry to 
get a handle for the device and communicate with the DCM 
to access and control the device and present the UI to the 
user. 

For example, FIG. 12A and 12 B show an exemplary UI 
display (e.g., on a television screen) for such a device(e.g., 
the camcorder). FIG. 12A shows a text menu display, where 
the user is presented with the various controls that can be 
modified using the control names and control values. For 
buttons, the user can select them (which equates to pushing 
a button). FIG. 12B shows a "next level" UI display for the 
camcorder Here, the user selected the main panel from the 
menu in FIG. 12A, and the display presents controls based 
on their grouping information. In the present embodiment, 
group names are used on a tabbed interface to allow the user 
to navigate between groups within the selected panel. 

Referring now to FIG. 13, a flow chart of a process 1300 
in accordance with one embodiment of the present invention 
is shown. Process 1300 shows the steps of a method for 
providing seamless interoperability and integration of a 
plurality of devices in a HAVI network by using the SDD 
information stored in each device. Process 1300 begins in 
step 1301, where a new device is coupled to a HAVI 
network. In step 1302, the device is queried to obtain a 
description (e.g., SDD) of level 1 functions supported by the 
device. In step, 1303, a level 1 DCM, which implements the 
level 1 functions, is generated for the device based upon the 
SDD. In step 1304, the device manager determines whether 
the new device contains software for a level 2 DCM. 

Referring still to FIG. 13, in step 1305, if the new device 
contains software for implementing level 2 functions, the 
software is retrieved from the device and in step 1306, a 
level 2 DCM which implements the level 2 functions is 
generated using the software. In steps 1307 and 1308, the 
device is continually accessed via the level 2 DCM. In steps 
1309 and 1310, if the new device does not include software 
for a level 2 DCM, the new device is continually accessed 
via the level 1 DCM, In this manner, the combination of the 
level 1 DCM and the level 2 DCM allow the present 
invention to provide seamless interoperability and integra- 
tion of the new device with the plurality of devices in the 
network. 

FIG. 14 shows a flow chart of a process 1400 in accor- 
dance with one embodiment of the present invention. Pro- 
cess 1400 shows the steps of a method for providing a basic 
command functionality and an expanded command func- 
tionality between a plurality of devices in a HAVI network. 
In step 1401, a device is coupled to a HAVI network which 
includes a FAV device. In step 1402, a generic level 1 DCM 
for the device is generated by the FAV device. As described 
above, the generic level 1 DCM is a basic abstraction of the 
capabilities of the device. The generic level 1 DCM enables 
the device to respond to a basic set of commands from the 
FAV device. In steps 1403 and 1404, the FAV device uses the 
generic DCM to query the device to determine whether the 
device includes descriptive information (e.g., SDD). As 
described above, the descriptive information describes the 
capabilities of the device. In step 1405, if the device includes 
descriptive information, the FAV device generates a param- 
eterized DCM for the device by modifying the generic DCM 
based upon the descriptive information. In steps 1406 and 
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1407, the device is continually controlled using the param- 
eterized level 1 DCM. In steps 1408 and 1409, if the device 
does not include descriptive information, the FAV device is 
continually controlled via the generic level 1 DCM. 

S Referring now to FIG. 15, a flow chart of a process 1500 
in accordance with one embodiment of the present invention 
is shown. Process 1500 shows the steps of a method for 
ensuring future upgradability and expandability of devices 
in HAVI network. In step 1501, a default level 1 DCM for 

10 a device coupled to the network is generated. As described 
above, the default level 1 DCM is configured to ensure at 
least a minimum degree of interoperability between the 
device and the other devices on the HAVI network. In step 
1502, the device is accessed by other devices via the default 

15 level 1 DCM. As described above, the default DCM enables 
the first device to respond to a default set of commands from 
other devices on the HAVI network In step 1503, an updated 
level 1 DCM for the devices is either received or not 
received. In step 1504, updated level 2 DCM for the device 

20 is either received or not received. As described above, the 
updates enable the device's capabilities and functionality to 
evolve (e.g., as new, more efficient software becomes 
available). 

In steps 1509 and 1508, where an updated level 1 DCM 

25 is received, the updated level 1 DCM is incorporated (e.g., 
this could involve merely modifying the current level 1 
DCM) and the device is continually accessed via this DCM 
until a later update is available. In step 1505, where an 
updated level 2 DCM is received, the DCM manager on the 

30 host FAV device unlinks the current DCM, and in steps 1506 
and 1507, the updated level 2 DCM is linked and the registry 
is updated to allow other devices within the HAVI network 
to access the updated level 2 DCM. This DCM is continually 
used for accessing the device until a later updated level 2 

35 DCM is received. In step 1510, if neither an updated level 
1 or an updated level 2 DCM is received, process 1500 
continues operation with the current DCM (e.g., the last 
installed DCM). 

FIG. 16 shows a flow chart of a process 1600 in accor- 

40 dance with one embodiment of the present invention. Pro- 
cess 1600 shows the steps of a method for providing 
seamless interoperability and integration of legacy devices 
with the HAVI compliant devices in a HAVI network. 
Process 1600 begins in step 1601, where a legacy device is 

45 coupled to the HAVI network. In step 1602, the legacy 
device is queried via the proprietary protocol to determine a 
set of basic capabilities of the legacy device. As described 
above, HAVI compliant devices use a common HAVI 
defined protocol. The legacy device typically communicates 

so with external devices (if at all) using a proprietary protocol. 
In step 1603, process 1600 maps a set of basic commands 
from the common protocol to the set of basic capabilities of 
the legacy device. In step 1604, a level 1 DCM for the legacy 
device is generated. As described above, the DCM is based 

55 upon the set of basic commands. In steps 1605 and 1606, the 
legacy device is continually accessed via the level 1 DCM 
such that the other HAVI devices are able to access the set 
of basic capabilities of the legacy device. 

FIG. 17A shows a flow chart of a process 1700 in 

60 accordance with one embodiment of the present invention. 
Process 1700 shows the steps of a method of controlling 
devices within a home audio/video network using an appli- 
cation program from an external service provider. In step 
1702, an application program is originated by a service 

65 provider (e.g., via cable television, internet web site, etc.) . In 
step 1703, the service provider communicates the applica- 
tion program from the service provider to an intelligent 



11/20/2003, EAST Version: 1.4.1 



6,o: 

27 

receiver/decoder device of the HAVI network over a logical 
channel. The application is subsequently instantiated within 
a computer readable memory unit of the intelligent receiver/ 
decoder. 

Referring still to FIG. 17A, in step 1704, the application 
program queries the HAVI registry of the device (e.g., FAV 
device) to locate DCMs on the network and selects a 
respective DCM from the registry. In step 1705, the down 
loaded application determines a communications point 
information from the selected DCM. In step 1706, the 
application controls a respective device of the HAVI net- 
work by communicating with the respective device using the 
communication point information. In step 1707, if the appli- 
cation needs to control another device, steps 1704 through 
1706 are repeated. If the application does not need to control 
another device, processes 1700 ends in step 1708. 

FIG. 17B shows a diagram of a HAVI network 1750 with 
the service provider 1720 in accordance with process 1700 
of FIG. 17A. As described above, the application program is 
downloaded from the service provider 1720 to the HAVI 
network 1750. The application is instantiated on the proces- 
sor 601 and memory 602 of the intelligent device (e.g., set 
top box 301). HAVI network 1750 also includes four HAVI 
devices, device 0 through device 3 (e.g., television, DVTR, 
etc.), 

DCM MANAGEMENT API 

An example DCM management API in accordance with 
one embodiment of the present invention is shown below. In 
the present embodiment, the common DCM commands 
include areas such as connection management, information 
and status queries for the device and its plugs etc. Regardless 
of the type of device represented by the DCM, such message 
sets need to be supported. 

The following is a list of DCM management messages 
that, in the present embodiment, all DCM's need to support 
for the HAVI architecture: 

ChannelUsage(plug); //returns the 1394 isoch. channel used 

by the specified unit plug 
PlugUsage(channel); // returns the plug associated with the 

specified channel 
GetDevicePlugCount(count); // returns the number of unit 

plugs on the device 
EstablishlnternalConneclion(sourcePlug, destPlug); 
EstablLshExternalConnection(sourcePlug, destPlug) 
StartDataFlow(plug); 
StopDataFlow(plug); 

GetSourceConnection(in dest, out source); // given a desti- 
nation plug, return the source to which it is connected 
(return the source plug of the transmitting device which 
shares the same isoch. channel) 

GetDestinationConnection(in source, out ); 

GetAllConnection( ); 

NotifyOnConnectionChange( ); 

GetDynamicConnectionCapability( ); // report whether the 
target device supports dynamic connection changes or not 
(e.g., a non-1394 device) 

LockConnection(plug); 

UnlockConnection(plug); 

GetConnectionStatus(plug); // status«busy, data transmis- 
sion format, channel, bandwidth usage, etc. 
Break! nte mal Con nection(plug); 
BreakExternalConnection(plug); 
GetInputSignalFormat(plug); 
setlnputSignalForrnat(plug); 

NotifylnputSignalFormat(plug); // send a notification if the 
signal format is changed. 
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GetSupportedlnputSignaIFormats(plug); // repeat the above 
for output signals 

GetFunctionInfo( ); // return information about the func- 
tional modules within the device (e.g., the AV/C subunits) 
5 GetDeviceType( ); 

GetVendorName( ); 

GetVendorLogo( ); 

SetDevicePowerState(powerstate); 

GetDevicePowerState(powerstate); 
10 GetSupportedPowerStates(list); 

NotiyPowerState(powerstate); 

ReserveDevice( ); 

GetDeviceReservationStatus( ); 

NotifyDeviceReservationStatus( ); 
15 VendorDependentCommand(command parameters); // pass 
thru a vendor-specific command in the native protocol; 

Function Control Module (FCM) Messages; 

The function-specific messages correspond to the typical 

native commands such as PLAY, STOP, REWIND for the 
20 VCR functionality within a device. Because we need to 

address these messages to a well defined location within a 

device, we use the FCM (Function Control Module) to 

represent the target of these messages. Like DCM's, there 

are some messages that have to deal with administration and 
25 management of FCM's. These messages are supported by all 

FCM's, independent of their particular domain. The mes- 
sages are as follows: 

GetFunctionType( ); II VCR, tuner, disc, etc. 
GetFunctionInfo( ); // more detailed information about the 
30 function, such as the particular kind of disc player (DVD, 
CD, etc.) 

GetNumberOfPlugs(inputPlugs outputPlugs); // returns the 
number of source and destination plugs for the functional 
module 

35 GetFunctionStatus( ); // current status of the functional 
module, including the status of source and destination 
plugs (input and output) 
GetPowerState(powerState); // functional modules may 
have individually controllable power states 
40 SetPowerState(powerState); 
GetSupportedPowerStates(list); 

GetSupportedDataFormats(list); // returns the data formats 

supported by this functional module 
NativeCommand(params); // send the functional module a 

45 command in its native command protocol 

The functional domain messages are based on the type of 
function (VCR, tuner, etc.). These are the typical PLAY, 
STOP, REWIND commands that one would expect. 
Level I interoperability includes both device-to-device 

50 and human-to-device interaction. The functional message 
sets such as PLAY, STOP and REWIND are used for 
device-to-device interaction. One example of this would be 
a video editing software package that wants to control any 
type of VCR; the program is designed with a very specific 

55 set of user interface controls which apply to all VCR's, 
When the user interacts with the application, the application 
in turn sends domain-specific commands such as PLAY and 
STOP to the target device. 

In the HAVI architecture, the application will send these 

60 messages to the DCM, and the DCM will translate them into 
the native language of the target BAV device. If the target 
device happens to support the HAVI messaging architecture, 
then these commands don't need to be translated at all; they 
are simply sent as HAVI message to the HAVI target. 

65 Camcorder devices are essentially VCR like. Their addi- 
tional functionality is part of the camcorder effects, 
transitions, etc. They are as follows: 
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stop() 
play( ) 
rewind( ) 
forward( ) 

record( ) s 
volume(sc lvalue) 

changeStatus(newMode) // newMode of: VTR, CAMERA, 
STANDBY 

cameraConlrol(controlType) // controITYPE defines control 
Type and subType structures eg zoom, zoom Value, or 10 
Effect, transition5 etc. 

MiniDiscs are of the category random access storage, they 
support a base set of commands to control PLAY, 
FORWARD, etc and a set of command specific to random 
access media. The commands are as follows: 15 
stopO 
play( ) 
rewind( ) 
forward( ) 

record( ) 20 
volume(setValue) 

changeStatus(newMode) // newMode of: STANDBY 

seek(track) 

seekstart( ) 

seekEnd( ) 25 
getDisklnfo( ) 

mdControl(controlType) // controITYPE defines control 
Type and subType structures eg intro mode, random play. 
Hard Disks are of the category random access storage, 

they support a base set of commands to control PLAY, 30 

FORWARD, etc and a set of command specific to random 

access media. The commands are as follows: 

stop( ) 

play( ) 

rewind( ) 35 
forward( ) 

record(type) //type structure passes info to allow intelligent 
devices to 

optimise storage policy changestatus(newMode) // new- 
Mode of: STANDBY 40 
seek(track) 
seek(block) 
seekStart( ) 
seekEnd( ) 

HDDControl(controlType) // controITYPE defines control 45 
Type and subType structures eg layout commands for 
block-structures 

With respect to user interfaces, it should be appreciated 
that a generic and simple UI may be a textual based one, as 
shown in FIG. 12 A. A more sophisticated one, based on 50 
DCM specialization, may be as shown on FIG. 12B. Where 
graphical information, carried in SDD is used by the generic 
DCM to specialize itself. 

Hence, the present invention provides a home audio 
visual (AV) network which defines an open architecture for 55 
inter-operating CE (consumer electronic) devices in a home 
network. The interoperability aspects of the present inven- 
tion define an architectural model that allows CE devices 
from any manufacturer to inter-operate and function seam- 
lessly within the user's home AV system. The system of the 60 
present invention includes a combination of a base set of 
generic device controls with an method to extend a base 
control protocol as new features and new CE devices are 
deployed within the home AV network. In so doing, the 
architecture of the present invention is extensible, and can be 65 
readily modified and advanced as market requirements and 
technology change. 



The foregoing descriptions of specific embodiments of the 
present invention have been presented for purposes of 
illustration and description. They are not intended to be 
exhaustive or to limit the invention to the precise forms 
disclosed, and obviously many modifications and variations 
are possible in light of the above teaching. The embodiments 
were chosen and described in order to best explain the 
principles of the invention arid its practical application, to 
thereby enable others skilled in the art to best utilize the 
invention and various embodiments with various modifica- 
tions as are suited to the particular use contemplated. It is 
intended that the scope of the invention be defined by the 
Claims appended hereto and their equivalents. 

What is claimed is: 

1. A method for providing device control and communi- 
cation for a plurality of devices in a network, the method 
comprising the steps of: 

a) coupling a device to the network, the network having 
a first set of devices previously coupled thereto; 

b) querying the device to obtain a description of first level 
functions supported by the device; 

c) generating a first level control software module for the 
device based upon the description of first level func- 
tions; 

d) receiving pseudo code from the device which imple- 
ments second level functions for the device; 

e) generating a second level control software module for 
the device using the pseudo code; and 

f) accessing the device via the first level control software 
module or the second level control software module to 
access the first level functions or the second level 
functions, respectively, such that communication and 
control of the device is provided by the first set of 
devices. 

2. The method of claim 1 wherein steps b) through d) are 
performed by a device manager executing on an intelligent 
device of the first set of devices in the network. 

3. The method of claim 1 wherein the first level control 
software module and the second level control software 
module both execute on an intelligent device of the first set 
of devices in the network. 

4. The method of claim 1 wherein the device is accessed 
by one of the first set of devices by accessing the first level 
control software module or the second level control software 
module, depending upon the capabilities of the device. 

5. The method of claim 1 wherein the first level control 
software module provides a minimum degree of interoper- 
ability for the device. 

6. The method of claim 5 wherein the second level control 
software module provides interoperability for the device that 
is enhanced in comparison to the first level control software 
module. 

7. The method of claim 1 wherein the network includes an 
IEEE 1394 local communication bus and the first level 
control software module and the second level control soft- 
ware module are configured to function within the IEEE 
1394 serial bus standard. 

8. The method of claim 1 wherein the first level control 
software module is generated for the device to provide a 
minimum degree of interoperability and further comprising 
the step of replacing the first level control software module 
with the second level control software module which pro- 
vides an enhanced degree of interoperability. 

9. The method of claim 1 wherein the first level control 
software module and the second level control software 
module both provide respective standardized control inter- 
faces for the device. 
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10. The method of claim 9 wherein the control interfaces 
include a software program which provides a predefined set 
of interoperability, functionality, and control interfaces for 
the device which enable seamless interoperability and inte- 
gration of the device with the first set of devices in the 
network. 

11. A home audio visual network including a plurality of 
devices coupled to a bus, wherein at least one of the devices 
includes a host device including a processor coupled to a 
computer readable memory, the memory containing com- 
puter readable instructions which when executed by the 
processor implement a method for providing communica- 
tion and control between the devices, the method comprising 
the steps of: 

a) querying a new device of the network to obtain a 
description of functions supported by the new device; 

b) generating a first level control software module for the 
new device based upon the description of functions 
supported by the new device; 

c) controlling the new device by using objects of the 
network, the objects of the network using the first level 
control software module; 

d) determining whether the new device includes a soft- 
ware program for a second level control software 
module having increased functionality with respect to 
the first level control software module; 

e) generating a second level control software module by 
using the software program; and . 

f) controlling the new device by using objects of the 30 
network, the objects of the network using the second 
level control software module. 

12. The home audio visual network of claim 11 wherein 
the new device is newly inserted into the home audio visual 
network and wherein the bus is of the IEEE 1394 serial 
communication standard. 

13. The home audio visual network of claim 11 wherein 
the first level control software module and the second level 
control software module are both execute simultaneously on 
the host device. 

14. The home audio visual network of claim 11 wherein 
the new device is accessed by one of the plurality of devices 
by accessing the first level control software module or the 
second level control software module on the host device. 

15. The home audio visual network of claim 11 wherein 
the first level control software module provides a predeter- 
mined minimum degree of interoperability for the device by 
providing a generalized interoperability interface. 

16. The home audio visual network of claim 15 wherein 
the second level control software module provides an 
enhanced degree of interoperability for the device in com- 
parison to the first level control software module by pro- 
viding a device specific interoperability interface. 

17. The home audio visual network of claim 11 wherein 
the first level and second level control software modules 
both provide control interfaces which provide a predefined 
set of interoperability, functionality, and control interfaces 
for the device which enable seamless interoperability and 
integration of the device with the plurality of devices in the 
network. 

18. A home audio visual network including a plurality of 
devices coupled to a bus, wherein at least one of the devices 
includes a host device having a processor coupled to a 
computer readable memory, the memory containing com- 
puter readable instructions which when executed implement 65 
a method for providing communication and control between 
the devices, the method comprising the steps of: 



a) querying a new device to obtain a description of 
functions supported by the new device; 

b) generating a first level control software module for the 
new device based upon the description, wherein the 
first level control software module provides a prede- 
termined minimum degree of interoperability for the 
device by providing a generalized interoperability 
interface; 

c) controlling the new device using the first level control 
software module; 

d) determining whether the new device includes software 
code for a second level control software module having 
increased functionality with respect to the first level 
control software module; 

e) generating a second level control software module by 
using the software code, wherein the second level 
control software module provides an enhanced degree 
of interoperability for the device in comparison to the 
first level control software module by providing a 
device specific interoperability interface; and 

f) controlling the new device using the second level 
control software module, wherein the new device is 
accessed by one of the plurality of devices by accessing 
the first level control software module or the second 
level control software module on the host device, 
thereby providing a first level of control or an enhanced 
second level of control. 

19. The home audio visual network of claim 18 wherein 
the first level control software module and the second level 
control software module both execute simultaneously on the 
host device. 

20. The home audio visual network of claim 19 wherein 
the first level and second level control software modules 
both provide control interfaces which provide a predefined 
set of interoperability, functionality, and control interfaces 
for the device which enable seamless interoperability and 

40 integration of the device with the plurality of devices of the 
network. 

21. An apparatus for providing device control and com- 
munication for a plurality of devices in a network, compris- 
ing: 

a) means for coupling a device to the network, the 
network having a first set of devices previously coupled 
thereto; 

b) means for querying the device to obtain a description 
of first level functions supported by the device; 

c) means for generating a first level control software 
module for the/ device based upon the description of 
first level functions; 

d) means for receiving pseudo code from the device 
which implements second level functions for the 
device; 

e) means for generating a second level control software 
module for the device using the pseudo code; and 

£) means for accessing the device via the first level control 
software module or the second level control software 
module to access the first level functions or the second 
level functions, respectively, such that communication 
and control of the device is provided by the first set of 
devices. 
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